openEHR
openEHR is a specification for storing clinical data in a way that survives changes to clinical practice, software vendors and database technology. Where FHIR is optimised for exchanging data, openEHR is optimised for persisting it.
- Tier 1 · openEHR International · https://openehr.org/ Specifications: https://specifications.openehr.org/
Two-level modelling
This is the central idea, and it is worth understanding even if you never deploy openEHR, because it explains a structural problem every health system has.
Level 1 — the reference model. A small, stable set of generic structures:
COMPOSITION, SECTION, OBSERVATION, EVALUATION, INSTRUCTION, ACTION,
plus data types (quantity, coded text, date/time, interval). It changes almost
never. Software implements this once.
Level 2 — archetypes. Formal, clinically authored models of individual concepts — blood pressure, body weight, adverse reaction, problem/diagnosis — expressed as constraints on the reference model, written in ADL (Archetype Definition Language). Archetypes are maintained by clinicians in a Clinical Knowledge Manager, not by developers in a schema migration.
Templates then constrain and combine archetypes for a specific use — an antenatal care contact form, a discharge summary.
Reference model ← implemented by software, stable for decades
▲
│ constrains
Archetypes ← authored by clinicians, versioned, shared
▲
│ constrains
Templates ← per use case, per organisation
▲
│
Data instances
The consequence: adding a new clinical concept does not require a database migration or a software release. The archetype is published, the template updated, and the system stores the new data. In an EMR whose clinical content changes every few months, this is a very large operational difference.
The archetype for blood pressure includes every attribute anyone might record — position, cuff size, limb, exertion — and a template selects the subset in use. That is deliberate: the storage model is maximal so that data recorded anywhere remains queryable, and the presentation is minimal.
AQL
Archetype Query Language queries data by archetype path rather than by table:
SELECT o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude AS systolic
FROM EHR e
CONTAINS COMPOSITION c
CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.blood_pressure.v2]
WHERE systolic > 140
The query is written against the clinical model and is portable across any conformant openEHR system, regardless of how that system physically stores the data. This is the property that makes vendor independence real rather than aspirational.
openEHR and FHIR
The framing as competitors is mostly a distraction. They solve different problems and are routinely deployed together.
| openEHR | FHIR | |
|---|---|---|
| Primary purpose | Persistence and querying of the clinical record | Exchange between systems |
| Model authority | Clinicians, via archetypes in a CKM | Standards committees, via resources and profiles |
| Change model | New archetype/template — no code change | New profile, often with implementation work |
| Granularity | Maximal dataset, then constrained | Pragmatic 80% of common use, then extended |
| Query | AQL, model-driven | REST search parameters |
| API | openEHR REST API (also FHIR-facing gateways) | REST, the point of the standard |
| Adoption pattern | National EHR platforms, vendor-neutral record repositories | Exchange, apps, national IGs, analytics |
| Learning curve | Steep — the modelling discipline is the product | Shallow to start, deep to do well |
| Ecosystem size | Smaller, concentrated in Europe, Brazil, Australia, India | Very large and growing |
The common combined architecture
Clinical applications
│ openEHR REST API (structured capture against templates)
▼
┌──────────────────────────────┐
│ openEHR clinical data │ ← vendor-neutral record, AQL queryable
│ repository │
└──────────┬───────────────────┘
│ mapping
▼
┌──────────────────────────────┐
│ FHIR facade │ ← what the outside world integrates with
└──────────┬───────────────────┘
▼
HIE · apps · analytics · other institutions
openEHR inside for durability and clinical modelling; FHIR at the boundary for exchange. See the FHIR facade pattern.
The mapping is real work. archetype→profile mapping is neither automatic nor lossless, and it has to be maintained as both sides evolve. Budget for it, and decide who owns it.
When to choose which
| Situation | Lean towards |
|---|---|
| You are building a national exchange between existing systems | FHIR |
| You are building a long-lived clinical data repository you intend to outlive several vendors | openEHR |
| Your clinical content changes frequently and is authored by clinicians | openEHR |
| You need third-party apps and a developer ecosystem | FHIR |
| You need both | Both — openEHR inside, FHIR at the edge |
| You have limited modelling capacity and a short timeline | FHIR |
That last row is not a slight on openEHR. Two-level modelling pays off when there is a clinical modelling function to sustain it. Without one, an openEHR deployment becomes a small number of templates that nobody updates, and the benefit evaporates.
ISO 13606
ISO 13606 shares openEHR's two-level architecture and reference model lineage, scoped to EHR extract communication. It is relevant mainly where national regulation cites it. Available from ISO (paid).
Ecosystem
| Project | Role | Notes |
|---|---|---|
| Clinical Knowledge Manager (CKM) | The international archetype repository | https://ckm.openehr.org/ |
| EHRbase | Open-source openEHR clinical data repository | Java, PostgreSQL; Tier 2 |
| Archetype Designer | Web tool for authoring archetypes and templates | Tier 2 |
| Better, Ocean, DIPS, Cambio | Commercial openEHR platforms | Tier 2, vendor |
| openEHR REST API specification | The standard API surface | https://specifications.openehr.org/releases/ITS-REST/latest/ |
References
- openEHR — https://openehr.org/
- openEHR specifications — https://specifications.openehr.org/
- Clinical Knowledge Manager — https://ckm.openehr.org/
- EHRbase — https://ehrbase.org/
- ISO 13606-1 — https://www.iso.org/standard/67868.html